Purpose
  • To verify the specification of a unit.
  • To verify the internal structure of a unit.
Steps
Input Artifacts: Resulting Artifacts:
Worker: Implementer
Guidelines:

Workflow Details:

Note: implementation and modification of components takes place in the context of configuration management on the project. Implementers are provided with a private development workspace (see Activity: Create Development Workspace) in which they do their work, as directed by Artifact: Work Orders. In this workspace, source elements are created and placed under configuration management, or modified through the usual check out, edit, build, unit test, and check in cycle (see Activity: Make Changes). Following the completion of some set of components (as defined by one or more Work Orders and required for an upcoming build), the implementer will deliver (see Activity: Deliver Changes) the associated new and modified components to the subsystem integration workspace, for integration with the work of other implementers. Finally, at a convenient point, the implementer can update (or rebaseline) the private development workspace so that it is consistent with the subsystem integration workspace (see Activity: Update Workspace).

Unit means not only a class in an object-oriented language, but also free subprograms, such as functions in C++.

For each unit (implemented class) you perform the following steps for unit testing:

Execute Unit Test To top of page

Purpose
  • To execute the test procedures (or test scripts if testing is automated)
Tool Mentors:

To execute unit test, the following steps should be followed:

  • Set-up the test environment to ensure that all the needed elements  (hardware, software, tools, data, etc.) have been implemented and are in the test environment.
  • Initialize the test environment to ensure all components are in the correct initial state for the start of testing.
  • Execute the test procedures.

Note: executing the test procedures will vary depending upon whether testing is automated or manual, and whether test components are needed either as drivers or stubs. 

  • Automated testing: The test scripts created during the Implement Test step are executed.
  • Manual execution: The structured test procedures developed during the Structure Test Procedure activity are used to manually execute the test.

Evaluate Execution of Test To top of page

Purpose
  • To determine whether the tests completed successfully and as desired
  • To determine if corrective action is required
Tool Mentors:

The execution of testing ends or terminates in one of two conditions:

  • Normal: all the test procedures (or scripts) execute as intended.

If testing terminates normally, then continue with Verify Test Results:

  • Abnormal or premature: the test procedures (or scripts) did not execute completely or as intended. When testing ends abnormally, the test results may be unreliable. The cause of termination needs to be identified, corrected, and the tests re-executed before additional test activities are performed.

If testing terminates abnormally, continue with Recover from Halted Tests, below.

Verify Test Results To top of page

Purpose
  • To determine if the test results are reliable
  • To identify appropriate corrective action the test results indicate flaws in the test effort or artifacts
Tool Mentors:

Upon the completion of testing, the test results should be reviewed to ensure that the test results are reliable and reported failures, warnings, or unexpected results were not caused by external influences (to the target-of-test), such as improper set-up or data.  

If the reported failures are due to errors identified in the test artifacts, or due to problems with the test environment, the appropriate corrective action should be taken and the testing re-executed.  For additional information, see "Recover From Halted Tests" below.

If the test results indicate the failures are genuinely due to the target-of-test, then the Execute Test Activity is complete and the next activity is to Evaluate Test.

Recover From Halted Tests To top of page

Purpose
  • To determine the appropriate corrective action to recover from a halted test
  • To correct the problem, recover, and re-execute the tests
Tool Mentors:

There are two major types of halted tests:

  • Fatal errors - the system fails (network failures, hardware crashes, etc.)
  • Test Script Command Failures - specific to automated testing, this is when a test script cannot execute a command (or line of code).

Both types of abnormal termination to testing may exhibit the same symptoms:

  • unexpected actions, windows, or events occur while the test script is executing
  • test environment appears unresponsive or in an undesirable state (such as hung or crashed).

To recover from halted tests, do the following:

  • determine the actual cause of the problem
  • correct the problem
  • re-set-up test environment
  • re-initialize test environment
  • re-execute tests
 
Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Display Rational Unified Process using frames

Rational Unified Process